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Abstract: In this report, we show how to use the Simple Fluent Calculus 
(SFC) to specify generic tracers, i.e. tracers which produce a generic trace. A 
generic trace is a trace which can be produced by different implementations of 
a software component and used independently from the traced component. 

This approach is used to define a method for extending a Java based CHR^ 
platform called CHROME (Constraint Handling Rule Online Model-driven En- 
gine) with an extensible generic tracer. The method includes a tracer specifi- 
cation in SFC, a methodology to extend it, and the way to integrate it with 
CHROME, resulting in the platform CHROME-REF (for Reasoning Explana- 
tion Facilities), which is a constraint solving and rule based reasoning engine 
with explanatory traces. 
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Towards a Generic Framework to Generate 
Explanatory Traces of Constraint Solving and 
Rule-Based Reasoning 

Resume : Dans ce rapport, nous montrons comment utiliser le calcul des 
fluents simple (SFC) pour specifier des traceurs generiques, c'est-a-dire qui pro- 
duiscnt des traces generiques. Une trace generique est une trace qui peut etre 
produitc par difi'erentcs implementations d'un composant logicicl et etre utilisees 
indcpendamment du composant trace. 

Cette approche est utilisee pour dcfinir unc mcthodc pour introduirc dans 
une platforme CHR^ basee Java ct appclcc CHROME (Constraint Handling 
Rule Online Model-driven Engine) un traceur generique extensible. La methode 
comprend une specification du traceur en SFC, une methodologie d'extension, et 
leur implantation dans CHROME, afin d'obtenir la plateforme CHROME-REF 
(Raisonnement Explicatif Facilite) , qui est un solveur de contraintes et moteur 
de raisonnement a base de regies avec des traces d'explications. 

Mots-cles : trace, CHR, CHR^, CHROME, CHROME-REF, MDE, traceur, 
meta-thcorie, pilote de tracer, analyseur, outils d'analyse, analyse de programme, 
analyse dynamique, semantique observationnelle, composant logiciel, deboggage, 
environnement de programmation, programmation en logiquc, validation 
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1 Introduction 

In this report we define a method for extending a Java based CHR^^ platform 
called CHROME (Constraint Handling Rule Online Model-driven Engine) with 
an extensible generic tracer. CHROME is presently developed at the Federal 
University of Pcrnambuc [56] with the purpose to allow the development of large 
software using CHR paradigm. 

The method consists of firstly to build a formal specification of a tracer for 
CHR^, the kernel of the system, and to extend it according to further CHR^ 
extensions. The specification defines a generic trace which is as independent as 
possible from a particular CHR platform or specific usages. Then, secondly, it 
is suggested to use this specification as a guideline to extend the MDE scheme 
development of CHROME, with a tracer scheme development, resulting in the 
plateform CHROME- REF (REF stands for Reasoning Explanation Facilities), 
which is a constraint solving and rule based reasoning engine with explanatory 
traces. 

This report is almost based on the internship work of R. Olivcira [38]. We 
introduce first some contextual aspects of this work. 

1.1 The CHR World 

The language CHR has matured over the last decade to a powerful and elegant 
general-purpose language with a wide spectrum of application domains [52]. 
The interest in CHR^ stemmed from past research having shown that: 

• CHR is simultaneously a Turing-complete declarative programming lan- 
guage and an expressive knowledge representation language with declara- 
tive formal semantics in classical first-order logic [22]; 

• CHR integrates and subsumes the three main rule-based programming and 
knowledge representation paradigms, i.e., (conditional) term rewrite rules 
[24], (guarded) production rules [55] and (constraint) logic programming 
rules [1]; 

• A CHR^ inference engine can support an unmatched variety of practi- 
cal automated reasoning tasks, including constraint solving with variables 
from arbitrary domains, satisfiability [22], entailment [50], abduction [1], 
agent action planning [50] and agent belief update [50] and revision [55]. 
In addition, it support several of these tasks under logical [50] , plausibilis- 
tic [8] and probabilistic epistemological [42] assumptions. [10] adds default 
reasoning to this list, by showing how to represent default logic theories 
in CHR^. It also discusses how to leverage this representation together 
with the well-know correspondence between default logic and Negation As 
Failure (NAF) in logic programming, to propose an extension CHR^'"°^ 
of CHR^ allowing NAF in the rule heads. And [20] adds concurrency. 

The Figure 1 shows the several automatic reasoning services that are sub- 
sumed by CHR^ and extensions. 

For all its above strengths, CHR remained until recently a language for 
Knowledge Representation and Programming (KR&P) in-the-small mainly used 

^CHR stands for Constraint Handling Rule [22], CHR^ for CHR with disjunction. 
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Figure 1: Rulc-bascd Constraint Programming and Automated Reasoning Ser- 
vices 



to fast prototype intelligent, innovative systems. The ORCAS project ^. consti- 
tutes a first and preliminary step towards the long term goal, to turn CHR into 
a platform for KR&P in-the-largc industrial strength, operationally deployed 
systems. It addressed one key KR&P in-the-large requirement, namely rule 
base engineering scalability through rule base encapsulation and assembly in 
reusable software components. 

1.2 From CHROME to CHROME-REF 

CHROME stands for Constraint Handling Rule Online Model-driven 
Engine, is a model-driven, component-based, scalable, online, Java-hosted CHR^ 
engine to lay at the bottom of the framework as the most widely reused auto- 
mated reasoning component. The idea of CHROME is also to demonstrate how 
a standard set of languages and processes prescribed by MDA can be used to 
design concrete artefacts, such as: a versatile inference engine for CHR^ and its 
compiler component that generates from a CHR^ base the source code of Java 
classes. 

The project CHROME-REF (Constraint Handling Rule Onhne Model-Driven 
Engine with Reasoning Explanation Facilities) constitutes a preliminary step, 
towards extending CHR and CHR engines with a formally founded, flexible 
and user-friendly reasoning explanation facility. The need for flexible and user- 
friendly explanatory reasoning tracing facilities for rule-based systems has been 

■^http : //www . cin . uf pe . br/- jr/mysite/C4RBCPProject . html 
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recognized since the initial success of production rule expert systems in the 80s. 
However, the expressive power of CHR being far superior than that of a mere 
production system, through the addition of functional terms, rewrite rules and 
backtracking search, makes debugging a CHR rule base also more complex than 
debugging a production rule base. In turn, this added complexity makes the 
need for sophisticated rule engine tracing facilities more crucial and the issues 
in their design and implementation more challenging. 

This project is pioneering the investigation of these issues. CHROME assem- 
bles CHR base independent run-time components for constraint store manage- 
ment, fired ruled history management, constraint entailment, query processing 
and intelligent search, with optimized components resulting from the compila- 
tion of the CHR base. Following the KobrA2 model-driven, component-based, 
orthographic software engineering method [4, 5], CHROME was built by first 
specifying a refined Platform-Independent Model (PIM) in the OMG standards 
UML2/ 0CL2 (Unified Modeling Language / Object Constraint Language). 
This PIM was then implemented in Java. 

The fact that CHROME compiling a declarative CHR base into imperative 
Java objects is crucial for its reasoning performance. However, it makes tracing 
far more complex since it introduces a mismatch between, on the one hand, the 
abstract, high-level rule interpretation operational semantics that the developer 
follows when conceiving a CHR base, and, on the other hand, the concrete, 
low-level object method call operational semantics effectively executed by the 
engine. To help the developer debug the rule base, the tracer must thus generate 
a high-level rule interpretation trace simulation from the low-level object method 
calls executed by the compiled code. 

Our objective here is to integrate the independently constructed tracer ar- 
chitecture within the component-based architecture of CHROME following the 
KobrA2 method. 

1.3 Towards Generic Trace 

Despite the fact that CHR^ provides an elegant general-purpose language with 
a wide spectrum of application domains, a key issue is how easily you can write 
and maintain programs. Several studies [48, 45] [7] [6] show that maintenance 
is the most expensive phase of software development: the initial development 
represents only 20% of the cost, whereas error fixing and addition of new fea- 
tures after the first release represent, each, 40% of the cost. Thus. 80% of the 
cost is due the to the maintenance phase. Debugging is said to be the least 
established area in software development: Industrial developers have no clear 
ideas about general debugging methods or effective and smart debugging tools, 
yet they debug programs anyway. There are several ways to analyze a program, 
for instance: program analysis tools help programmers understand programs, 
type checkers [37] help understand data inconsistencies, slicing tools [30] help 
understand dependencies among parts of a program. Tracers give insights into 
program executions. 

At present, there exists a number of useful debugging tools for CHR, for 
example, ECLiPSe Prolog [2], SWTProlog [58] or CHROME [56]. But, these 
tools were designed and implemented in a specific way for each solver, not all 
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Figure 2: Current situation: each solver is strictly connected to its debugging 
tool. Figure adapted from [31] 

tools benefit from all the existing tool. The Figure 2 shows this current cenario, 
for each CHR solver a specific implementation of the debugging tool. 

This way each implementation results in a set of one-to-one specialized con- 
nections between a solver and its tools. If we want to interchange data between 
each solver, hooks have to be added into the solver code in order to be able to do 
it. Furthermore, the types of basic information required by a given debugging 
tool is not often made explicit and may have to be reverse-engineered. This is a 
non neglectable part of the cost of porting debugging tool from one constraint 
programming platform to another. 

In order to solve the above-mentioned problem and improve analysis and 
maintenance of rule-based constraint programs, like CHR^, there is a need for 
user-friendly reasoning explanatory facilities that are flexible and portable. 

Given this scenario we take advantage of the recent research in trace en- 
gineering [16, 14, 15] to propose a generic architecture that produces generic 
debugging informations for CHR^ and potential extensions. In that way, any 
debugging tool changes its focus to generic traces, instead of to be concerned in 
specific platform implementations. 

The Figure 3 illustrates the idea of "generic trace" , which is as independent 
as possible from a particular CHR platform or specific usages. It shows the 
structure of a tracing process which can be decomposed into three likely "in- 
dependent" components: trace extraction, full trace filtering according to some 
query, and reconstruction of a sub-trace to be used. It shows also the several 
aspects which must be specified: a semantics for the generic trace (called Ob- 
servational Semantics), a query language to select the sub-trace of interest to 
be used, and a semantics to interpret the selected trace (called Interpretative 
Semantics). 
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Figure 3: Our approach: a generic trace schema enables work and maintain just 
one process of debugging 



RR n° 7165 



8 



Deransart & OliveAra 



CHR-OS 




FC 



CHROME-REF 



UML 



CHROME 



UML 



Figure 4: Towards CHROME-REF 



A generic trace needs to be understood independently from the observed 
process. For this reason it is necessary to be able to give it a semantics as 
precise as possible. This is the purpose of the Observational Semantics. It 
will allow for validation tests and studies of some trace properties before and 
after implementing it. In this report we focus on the observational semantics of 
traces. 

The Fluent Calculus (FC) is a logic-based representation language for knowl- 
edge about actions, change, and causality [54]. As an extension of the classical 
Situation Calculus [43], Fluent Calculus provides a general framework for the 
development of axiomatic semantics for dynamic domains. It appears to be well 
suited to describe the Observational Semantics and, though its Flux implemen- 
tation [53], to be a likely executable specification. 

1.4 Connecting all the Pieces 

The CHROME project focuses on extending CHR with rule-base encapsula- 
tion in software components for reuse by assembly across applications. It has 
as intention to produce the first domain-independent framework highly reusable 
debugging tool, supporting a variety of reasoning explanation facilities. The 
main contribution is to permit any CHR^ engine to be extensible with com- 
ponents for comprehensive, flexible and efficient reasoning explanation trace 
generation and user-friendly trace query specification and trace visualization. 
To achieve this is necessary to integrate design patterns for tracing facilities 
such as tracer driver with design patterns for Graphical User Interface (GUI) 
such as Model- View-Controller (MVC) within an overall Model-Driven Archi- 
tecture (MDA) framework [3] . It will also involve defining a comprehensive trace 
query language, as well as experiments to empirically evaluate the engineering 
productivity gains obtained through the use of the tracing components. 

In the report we describe the approach illustrated by the Figure 4. It consists 
first in an observational semantics of the extensible generic trace of CHR which 
is specified in Fluent Calculus. This semantics is thus mapped into the PIM 
description of CHROME, leading to a complete PIM of CHROME-REF in UML, 
the constraint solving and rule based reasoning engine with explanatory traces. 

The CHROME-REF environment will be built such an editor as a Eclipse 
Plugin for rapid prototyping deployed with a GUI to interactively submit re- 
quests and inspect solution explanations at various levels of details. 

The rest of this report is organized in three main sections. 

■^http:/ /www. eclipse. org/ 
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The Section 2 presents a restricted trace meta-theory focused on trace pro- 
duction components and composition. It introduces also the observational se- 
mantics of a trace and its representation in the simplified fluent calculus. 

The Section 3 presents the observational semantics of CHR^ in fiuent cal- 
culus including tracer and extraction schemes. 

The Section 4 shows the introduction of the tracer in the PIM of CHROME 
using the KobrA2 method and resulting in a PIM of CHROME-REF with a 
very first implementation. 

Four annexes give respectively a description of the Observational Semantics 
of CHR in SFC, the XML scheme of a generic trace of CHR^, a short example 
of trace produced by the Java compiled CHROME-REF, and the OS of an 
application. 
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2 Specifying Tracers 

The Trace Meta-Theory (TMT) [15] provides a set of definitions about how to 
design a trace for a specific domain of observation. 

A trace may be interpreted as a sequence of communication actions that 
may take place between an observer and an observed process. It consists of 
finite unbounded sequences trace events. There is also the tracer that means the 
generator of trace. According to [14], the TMT focuses particularly on providing 
semantics to tracers and the produced traces as independent as possible from 
those of the processes or from the ways the tracers produce them. 

There are two concepts of trace [14] (cf. the Figure 5 and the Section 2.2). 
The first one is the virtual trace, it represents a sequence of events showing 
the evolution of a virtual state which contains all that one can or wants to 
know about the observed process. The second one is called actual trace, it 
represents the generated trace in the form of some encoding of the current virtual 
state. Finally, there is the idea of full trace if the parameters chosen to be 
observed about the process represent the totality of useful knowledge regarding 
it (explicitly or implicitly). 



2.1 Components of Trace Generation and Use 

The Figure 6 shows the different components related to a unique trace. We 
distinguish 5 components, in this order. 

1. Observed process 

The observed process is assumed more or less abstracted in such a way that 
his behavior can be described by a virtual trace, that is to say, a sequence 
of (partial) states. A formal description of the process, if possible, can be 
considered as a formal semantics, which can be used to describe the actual 
trace extraction. 









Windows 



CHR program compiled into Prolog 



Program written in CHR 



Prolog 



CHR 



VirtualTrace 



CHR 
Program 



Rebuild 



I 



Extraction 



->l Actual Trace 



Figure 5: Virtual and Actual Trace. 



2. Extractor 

This component is the extraction function of the actual trace from the 
virtual trace. From a theoretical point of view, we can see it as a specific 
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component, but in practice it corresponds to the tracer whose reahzation, 
in the case of a programming language, usually requires modifying the 
code of the process. 

3. Filter 

The role of the filter component, or driver [32], is to select a useful sub- 
trace. This component requires a specific study. It is assumed here that 
it operates on the actual trace (that produced by the tracer). The fact 
of making it as a proper component corresponds to the specific approach 
adopted here, which implies that the extracted actual trace is full. The 
filtering depends on the specific application, implying that the full trace 
already contains all the information potentially needed for various uses. 

4. Rebuilder 

The reconstruction component performs the reverse operation of the ex- 
traction, at least for a subpart of the trace, and then reconstructs a se- 
quence of partial virtual states. If the trace is faithful (i.e. no information 
is lost by the driver) [15], this ensures that the virtual trace reconstruc- 
tion is possible. In this case also, the separation between two components 
(rebuilder and analyzer) is essentially theoretical; these two components 
may be in practice very entangled. 

5. Analyzer 

The component using a trace may be a trace analyzer or any application. 



With these components it may be associated three main specification steps, 
as illustrated on the Figure 7. 

- Observational Semantics (OS) 
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The OS describes formally the observed process (or a family of processes) and 
the actual trace extraction. This aspect will be studied deeper in the Sec- 
tion 2.2. The intention here is to express the OS using simple fluent calculus. 

- Querying 

Due to the separation in several components, the actual trace may be ex- 
pressed in any language. We suggest using XML. This allows to use standard 
querying techniques defined for XML. This aspect will not be developed here, 
but we chose to express the trace in XML and give in the Appendix B the 
corresponding XML schema. 

- Interpretative Semantics (IS) 

The interpretation of a trace, i.e. the capacity of reconstructing the sequence 
of virtual states from an actual trace, is formally described by the Interpreta- 
tive Semantics. In the TMT no particular application is defined; its objective 
is just to make sure that the original observed semantics of the process has 
been fully communicated to the application, independently of what the appli- 
cation does. 

2.2 Contiguous Full Traces 

We introduce here the two traces which may be associated to a single process 
equipped with a tracer. We recall here the definitions used in [15]. 

2.2.1 Virtual Trace 

A full virtual trace is defined on a domain of states. Given V a finite set of 
(names) of parameters pi defined on the domains Vi- The Vi are domains of 
objects of any kind. They may also have relations (functional or otherwise) 
between them and they can be infinite in size. 

A domain of states S is defined on the Cartesian product of the parameter 
domains: S CVi x ... xVn- 

Definition 1 (Contiguous Pull Virtual Trace) A contiguous full virtual trace 
is a sequence of trace events of the form Ct '■ {t, rt, St), t > 1, where: 

• t: is the chrono, specific time of the trace. It is an integer increased 
by one unit in each successive event. To point a particular value of the 
chrono, we will talk about moment of the trace. 

• rt: an identifier o/ action characterizing the type of actions undertaken 
to make the transition from state st-i to state Sf. 

• St: is an element of the state domain, st = Pi.t, •••,Pn,t is the current 
state reached at moment t, and the pi_t are values of the parameters pi 
at moment t. Sf is the current full virtual state. 

A finite virtual trace over t {t > 0) events will be denoted —< sq, et >, where 
So is the initial full virtual state and represents the sequence ei . . . . . . Cj. 

The full virtual trace is contiguous insofar as all the moments in the interval 
[l..t] are present in the trace =< so,et >. 
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2.2.2 Actual Trace 

The full virtual trace represents what wc want or what is possible to observe of 
a process. It describes the development stages of this process in the form of the 
evolution of a state which contains the observables. As the current virtual state 
of a process can be fully represented in this trace, one cannot expect neither 
to produce it nor to communicate it efficiently. In practice we will perform a 
kind of "compression" of the information conveyed by the virtual states and 
their evolution, transmitted or communicable to the process observers, and one 
shall ensure that these processes are able to "decompress" it. This actually 
communicated information is the actual trace. 

An actual full trace is defined on an actual state domain. Let ^ be a finite set 
of (names of) attributes a,; defined on domains of attributes At- The attributes 
may have relationships (they are not necessarily independent) and they can be 
infinite in size. 

An actual state domain A is defined on the Cartesian product of attributes 
domains: A Ai x ... x An- 

Definition 2 (Contiguous Full Actual Trace) An actual trace is a sequence 
of trace events of the form Wt '■ (t,at), t > 1, where: 

t is the chrono and at ^ A denotes a finite sequence of attributes values, at is 
the current actual state. The number of attributes of a trace event is bound by n. 
Each state at contains at most n attributes whose number depends exclusively 
on the type of action which produced it. 

An actual trace with t {t > 0) events is denoted T™ sq,w^ >, where sq is 
the initial virtual state common to both traces and uh represents the sequence 

Wi, . ..Wi,...,Wt. 

2.3 Generic Trace and Composition 

We study here the methodology of generic full trace development for a multi- 
layer based application. 

2.3.1 Generic Trace of a Familly of Observed Processes 

Consider again the Figure 3 in the introduction. It illustrates the fact that 
different implementations of CHR can be abstracted by a unique simpler model. 
This common model is used to specify the unique virtual and actual traces of 
these implementations. This illustrates the way we will proceed to get a generic 
trace of CHR: starting from an abstract theoretical, general but sufficiently 
refined, semantics of CHR which is (almost) the same implemented in all CHR 
platforms. 

2.3.2 Composition of Traces 

Now wc consider the case of an application written in CHR. It may be for 
example a particular constraints solver like CLP(FD). In this case there exists 
already a generic trace called GenTra4CP [12]. This trace is generic for most of 
the CLP(FD) existing constraints solvers. Therefore a tracer of CLP(FD) solver 
implemented in CHR should also produce this trace. But we may be interested 
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in refining the trace considering that there are two layers: the layer of the 
application (CLP(FD)) and the layer of the language in which it is implemented 
(CHR). The most refined trace will then be the trace in the GenTra4CP format 
extended with elements of the generic full trace of CHR alone. The generic full 
trace of CLP(FD) on CHR is an extension of the application trace taking into 
account details of lower layers. 

This is illustrated by the Figure 8 in the case of two layers: an application 
(like CLP(FD) for example) implemented in CHR. This method can be general- 
ized to applications with several layers of software. The Figure 5 shows in fact 
at least 4 layers. 

In our components based approach it means that we may define separately 
and independently specific generic full traces for each layer, and, so in this case 
for the application (APL) and the under-layer of CHR. The generic full trace 
APL on CHR is a kind of composition of traces and will be obtained by some 
merging of both generic full traces into a unique one. The result may not exactly 
be a union of all actions, parameters and attributes, but it is not our purpose 
here to study more deeply this aspect. For more details see [15]. 



2.4 Observational Semantics 

The Observational Semantics (OS) is a description of a possibly unbounded data 
fiow without explicit reference to the operational semantics of the process which 
produced it [16]. The OS may be considered as a abstract model of process, in 
the case of a single observed process or it can be an abstraction of the semantics 
to several processes. It is defined as a Labelled Transition Systems (LTS) [25]. 
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2.4.1 Representation of the Observational Semantics 

The Observational Semantics has two parts: a state transition function and a 
trace extraction function. 

The first part is a formal model on the way successive events of the virtual 
trace are related. It is a virtual trace semantics in the sense that, given a full 
virtual trace 

Tj" =< soje* >i it explains the sequence of events et by a transition function'^ 
recursively applied from an initial virtual state. 

The second part, the function of extraction, produces what is actually "broad- 
casted" outside from the observed process. This function has as arguments the 
current state and the type of action, and produces the attributes of the actual 
trace. 

Definition 3 (Observational Semantics (OS)) An Observational Semantics 
is defined by the tuple < S, Rq, A, E^T, Sq >, where 

• S is a virtual state domain, where each state is described by a set of 
parameters. 

• Ro is a finite set of action types, set of identifiers used as labels for tran- 
sitions. 

• A is a actual state domain, where each state is described by a set of at- 
tributes. 

• E is the local extraction function of the actual state a, performed by tran- 
sition of action type r issued from state s , E : R x S ^ A, which satisfies 
by definition: E{r,s) = a (a € A, set of actual states). More precisely, 
the set of attributes at of the event t of the actual trace is derived from 
the current state at moment t — 1 of the virtual trace and the transition 
labelled by the action type rt, i.e. 

E{rt,st-i) = at 

• T state transition function T : R x ^ S , i.e. 

T[rt,st-i) = St 

• Sq ^ S , set of initial states. 

The OS may be represented by "rules" , one for each action, describing the 
transition and the actual trace event extraction corresponding to the action. A 
rule has 4 items. 

• AType: an action identifier r G Ro 

• ACond: { some auxiliary computations on the current virtual state and 
condition for executing the action corresponding to the transition: a first- 
order logic formula using predicates on the parameters } 

■^It is fact a relation since the transitions may be nondcterministic. 
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• VSEffect: { the effect of the action r on the current state s, resulting in 
a new state s' , and some auxihary computations relative to the attributes 
of the trace event } 

• Etrace: { the attributes of the trace event produced by the action r: a, 
new extracted actual trace event } 

Example 2.1: the Fibonacci Function 

Idealized (biologically unrealistic) rabbit population. 

The OS < S,If,Ro,A,E,T,So >, describes the deterministic transition 
function Ti. 

S: J\f^ (positive integers list), st is the complete evolution of the population 
from moment until moment t + I: St ~ [popuo, ■ ■ ■ ,poput,poput+i] 
Ro- {n^g} (monthly growing) 

A: A/+, at is the population at moment t + 1 (popu(t + 1)). 

E: E{mg, s) = plasties) + last{s). There is one rule only to describe E. 

Ti: T{mg,s) = s o [plast{s) + last(s)] (respectively before last and last 
elements of the list ss, o denote lists concatenation). The new virtual state t is 
the previous state to which the sum of the two last elements is appended. 

Sq: sq = [1, 1]. 

AType: mg 
ACond: { true} 

VSEffect: {v^ plast{s) + last{s) A s' ^ s o [v] } 
Etrace: {v} 

Traces: 

=< [1, 1], [(1, mg, [1, 1, 2]), (2, mg, [1, 1, 2, 3]), . . . , 

(4, mg, [1, 1, 2, 3, 5, 8]), (5, mg, [1, 1, 2, 3, 5, 8, 13])] > 
=< [1, 1], [(1, 2), (2, 3), (3, 5), (4, 8), (5, 13)] > 

2.4.2 Simple Fluent Calculus 

The Fluent Calculus (FC) is a logic-based representation language for knowl- 
edge about actions, change, and causality [54]. As an extension of the classical 
Situation Calculus [43], Fluent Calculus provides a general framework for the 
development of axiomatic semantics for dynamic domains. 

The simple fluent calculus (SFC) has the following appealing qualities: 

- Simplification of the description, since the notions of virtual state and actual 
trace are "naturally" embedded in the fluent calculus (the situation corre- 
sponding to a state can be viewed as a representation of the actual trace). 

- Reasoning on transitions may be simpler, as it supports handling partial vir- 
tual states (with appropriate axiomatisation) . Formal proofs become simpler 
in the SFC (less deductions, at least for "direct closed" effects, see [54, 51]). 
It follows that properties like "faithfulness" [16] should be easier to prove 
formally. The Symmetry of "state axioms" allows forward and backward rea- 
soning. With the simplicity of the representation of state changes, this should 
make such proofs simpler. 
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- The description in SFC makes such specification potcntiaUy executable in 
Flux. There is some limits to the exccutability, related to the partial axioma- 
tisation of the observational semantics and exccutability of formal specification 
in general. However such framework may facilitate some simulations. 

The Fluent Calculus is a sorted logic language with four standard sorts: 
FLUENT, STATE, ACTION, and SIT (which stands for situation). A fiucnt 
describes a single state property that may change by the means of the actions of 
some agent. A state is a collection of fluents. Adopted from Situation Calculus, 
the standard sort SIT describes sequences of actions. 

The pre-defined constant : STATE stands for the empty state. Each term 
of sort FLUENT is also an (atomic) STATE, and the function o : STATE x 
STATE M- STATE, written in infix notation, represents the composition of 
two states. The following abbreviation Holds{f, z) is used to express that fiuent 
/ holds in state z: 

Holds{f,z)^def{^z')foz' = Z (1) 

The behavior of function "o" is governed by the foundational axioms of 
Fluent Calculus, which essentially characterize states as sets of fluents. 

(Zl O Z2) O Z3 = Zl O {Z2 O Z3) (2) 
Zl O Z2 = Z2O Zl (3) 

z o z ~ z (4) 
Zl o = z (5) 

Holdsif, /i o z) D /i V Holdsif, z) (6) 

States can be updated by adding and/or removing one or more fluents. 
Addition of a sub-state z to a state zi is simply expressed as Z2 = zi o z, 
and removal is deflned by 

Z2 = Zl — z =def {Holds{f, Z2) = Holds{f, Zl) A -^Holds{f, z)) (7) 

The standard predicate Pass : ACTION x STATE in Fiucnt Calculus is 
used to axiomatize the conditions under which an action is possible in a state, 
i.e., the situations in which the pre-condition of this actions is satisfied. 

The pre-defined constant 5*0 : SIT is the initial (i.e., before the execution 
of any action) situation. The function Do : ACTION x SIT i-> SIT denotes 
the addition of an action to a situation. The standard function State : SIT t-^ 
STATE is used to denote the state, i.e., the fluents that hold in a situation, 
after a sequence of actions. This allows to extend macro Holds and predicate 
Pass to SITUATION arguments as follows. 

Holdsif, s) ^def Holdsif, State{s)) (8) 
Poss{a,s) ^def Possia, Stateis)) (9) 
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In a Fluent Calculus Axiomatization, beyond the definition of the domain 
sorts, functions and predicates, we can define a set of axioms that must follow 
three pre-defined axiom schemas: the precondition axioms, the state update 
axioms and the state constraint axioms. 

Definition 4 (Pure State Formula) A Pure State Formula is a First Order 
formula Tl{z) 

• There is only one free state variable z 

• It is composed of atomic formulas in the form: 

Holds{(f>, z), where (p is of the sort FLUENT 

atoms which do not use any reserved predicate of Fluent Calculus 

Definition 5 (Precondition Axiom) A precondition axiom follows the schema: 
Poss{A[x), z) = T\{x,z), where n(af, z) is a Pure State Formula. 

This kind of axiom states that the execution of the action A with the pa- 
rameters X is possible in the state z if and only if \1a{x^ z) is true. 

Definition 6 (State Update Axiom) A state update axiom follows the schema: 
Poss{A{x), State{s)) AU{x, State{s)) D T{State{Do{A{x), s)), State{s)) 
where 

T{State{Do{A{x), s)), State{s)) = State{Do{A{x), s)) = State{s) o-d+ 
where 

'd^ and i?~ are partial states. 

2.4.3 Observational Semantics in Simple Fluent Calculus 

A virtual state of the observed process corresponds to a state in SFC described 
by a set of fluents (this correspondence must be explicitly specified) . 

Each type of action in the OS is an action name in the SFC. A particular 
action is denoted R in the following. 

Actual states are elements of the Cartesian product of attribute domains 
(this domain must be explicitly specified). 

Transition and extraction function (or relation) are described using both 
fundamental following schemes (fundamental axioms of the Fluent calculus) 

1. Pre-Condition Axioms: 

Poss{R, X, z) = n(x, z) 

2. State Update Axioms: 

Poss(R, X, State(s)) A Il{x.y, State(s)) D 

T ji{State{Do{R, w{x.y, State{s)), s)), State{s)) 

where w{x.y, State{s)) is an actual trace event associated with the tran- 
sition, and derived from the current state (using local variables too). 
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There are as many pre-conditions and state update axioms as there are action 
types R in the OS. Tn may be a disjunction. It defines the new virtual state 
and the corresponding extracted actual trace event attributes w{x.y, State{s)). 

Nota: a situation s contains the sequence of actions in the OS executed to 
reach the current virtual state z = State{s), and also the sequence of extracted 
actual trace events such that T™ = E{T'"). 

An actual trace T'^ is the sequence of Wi, with chrono, found in the situation 

s = Do{R Do{Rn-l,Xn^l,Wn-l, Sq)...) 

It may be computed according to the following axioms: 
Extraction{0, S) = S 

Extraction{n + 1, Do{R, x, w, s)) — {{n + 1) .w) .Extractionin, s) 
Example 2.2: OS for Fibonacci 

The virtual state contains only one fluent Fib/1 of type List{Int)— > 
Fluent, and there is only one type of action Mg. The actual state contains 
just 2 attributes, respectively of type String and Int. A vector is represented 
by a sequence (Prolog list syntax). 

So = ^([1, 1]) 

Poss{Mg, [l,pl],z) = Holds{Fib{[l,pl\x]),z) 

Poss{Mg, [I, pi] , State{s)) Av = l+plD 

State{Do{Mg, [Mg,v\,s)) = State{s) o Fih{[v,l,pl\x]) ~ Fib{[l,pl\x\) 

2.5 Trace Query and Analysis Tools 

Trace query and analysis tools are considered here as separate components, 
as illustrated in the Figure 6. Although they are part of the CHROME-REF 
project, they are not studied more deeply here. Instead, we propose a first 
repesentation of the actual CHR trace using XML. The XML schema is given 
in the Appendix B, and an example of produced trace in the XML format in 
the Appendix C. 
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3 Tracing Rule-Based Constraint Programming 

Constraint Handling Rules emerges in the context of Constraint Logic Program- 
ming (CLP) as a language for describing Constraint Solvers. In CLP, a problem 
is stated as a set of constraints, a set of predicates and a set of logical rules. 
Problems in CLP are generally solved by the interaction of a logical inference 
engine and constraint solving components. The logical rules (written in a host 
language) are interpreted by the logical inference engine and the constraint 
solving tasks are delegated to the constraint solvers. 

3.1 CHR by Example 

The following rule base handles the less-than-or-equal problem: 

reflexivity rl® leq(X,Y) <=> X=Y | true. 

antisymmetry r2a leq(X,Y) , leq(Y,X) <=> X=Y . 

Idempotence r3(S leq(X,Y) \ leq(X,Y) <=> true. 

transitivity r4(S leq(X,Y) , leq(Y,Z) <=> leq(X,Z). 

This CHR program specifies how leq simplifies and propagates as a con- 
straint. The rules implement reflexivity, antisymmetry, idempotence and tran- 
sitivity in a straightforward way. CHR reflexivity states that leq{X, Y) simpli- 
fies to true, provided it is the case that X ~ Y. This test forms the (optional) 
guard of a rule, a precondition on the applicability of the rule. Hence, whenever 
we see a constraint of the form leq{X,X) we can simplify it to true. 

The rule antisymmetry means that if wc find leq{X, Y) as well as leq{Y, X) 
in the constraint store, we can replace it by the logically equivalent X = Y. 
Note the different use oi X = Y in the two rules: in the reflexivity rule the 
equality is a precondition (test) on the rule, while in the antisymmetry rule it is 
enforced when the rule fires. (The reflexivity rule could also have been written 
as reflexivity@leq{X, X) <=> true.) 

The rules reflexivity and antisymmetry are simplification CHR. In such 
rules, the constraint found arc removed when the rule applies and fires. The 
rule idempotence is a simpagation CHR, only the constraint in the right part of 
the head will be removed. The rule says that if we find leq{X, Y) and another 
leq{X, Y) in the constraint store, we can remove one. 

Finally, the rule transitivity states that the conjunction leq(X, Y), leq{Y, Z) 
implies leq{X,Z). Operationally, we add leq{X,Z) as (redundant) constraint, 
without removing the constraints leq{X,Y),leq{Y, Z). This kind of CHR is 
called propagation CHR. 

The CHR rules arc interpreted by a CHR inference engine by rewriting the 
initial set of constraints by the iterative application of the rules. Its extension 
with disjunctive bodies, CHR^ boosts its expressiveness power, turning it into 
a general programming language (with no need of an host language). 

3.2 Observational Semantics of CHR 

The observational semantics of a tracer is based on a simplified abstract se- 
mantics of the observed process. In the case of CHR"^, we suggest to use an 
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adaptation of the refined theoretical semantics of CHR as presented in [17]. To 
start with, we show how to build an observational semantics for CHR based on 
the theoretical operational semantics ujt [22] . The description of in SFC is 
borrowed from [9]. 

3.2.1 Theoretical Operational Semantics uit of CHR 

We define CT as the constraint theory which defines the semantic of the built-in 
constraints and thus models the internal solver which is in charge of handling 
them. We assume it supports at least the equality built-in. We use [H\T] to 
indicate the first (H) and the remaining (T) terms in a list, H — h for sequence 
concatenation and [] for empty sequences. 

We use the notation aq, . . . , a„ for both bags and sets. Bags are sets which 
allow repeats. We use U for set union and W for bag union, and {} to represent 
both the empty bag and the empty set. The identified constraints have the 
form c#i, where c is a user-defined constraint and i a natural number. They 
differentiate among copies of the same constraint in a bag. We also assume the 
functions chr{c^i) = c and id{c^i) = i. 

An execution state is a tuple {Q,U,B,P)„, where Q is the Goal, a bag of 
constraints to be executed; U is the UDCS (User Defined Constraint Store), a 
bag of identified user defined constraints; B is the BICS (Built-in Constraint 
Store), a conjunction of constraints; P is the Propagation History, a set of 
sequences, each recording the identities of the user-defined constraints which 
fired a rule; n is the next free natural used to number an identified constraint. 

The initial state is represented by the tuple (Q, [],true, [])„. The transitions 
are applied non-deterministically until no transition is applicable or the current 
built-in constraint store is inconsistent. These transitions are defined as follows: 



Solve ({c} l+l Q, U, B, P)„ t-^ (Q, U,cAB, P)„ where c is 
built-in 

Introduce {{c}iSQ,U, B, P)^ ^ (Q, {c#n} W U, B, P)„+i 
where c is user-defined constraint 
Apply (Q, Hi^H^m, B, F)„ ^ {C^Q, i?i WC/, eAS, 
where exists a rule r@H[ \ H2 g [C and a matching sub- 
stitution e, such that chr{Hi) = e{H[),chr{H2) = e{H2) 
and CT \= B ^ 3{e A g); and the sequence id{Hi) + 
+id{H2) + +id[r] ^ P; and P' = P U id{Hi) + +id{H2) + 
+ W 



Example 3.1 The following is a (terminating) derivation under uit for the 
query leq{A, B),leq{B,C),leq{C, A) executed on the leq program in Example 
3.1. For brevity, P have been removed from each tuple. 
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{[leq(A, B),leq{B, C), leg{C, A)}, 0, 0>i (1) 

^„.f™d„c«;e9(B, C),leq{C, A)}, {leq{A, B)#l}, 0)^ (2) 

^,„hW„c{{ieg(aA)},{(eg(A,B)#l,(eg(B,C)#2},0)3 (3) 

(transitivity 1-4 Jf = A A y = ^^pply {{leq{C,A),leq{A,C)},{leq{A,B)#l,leq{B,C)#2},li)3 (4) 
BAZ = C) 

^,„.,w„c{{ieg(a A]}, {leq{A, B)#l, leq{B. C)#2, leq{A, C)#3}, 0)4 (5) 

^,„i™d„40, {ieg(A, ie?(B, C)#2, leq(A, C)#3, ie<!(C, A)#4}, 0)5 (6) 

(antisymmetry r2 Ji: = C A ^apply {lll,{leq(A,B)#l,leq{B,C)#2},{A = C})s (7) 

Y = A) 

(antisymmetry r2 JV: = C A ^apply (0, 0, {A = C, C = B}),, (8) 

Y = A) 

No more transition rules are possible, so this is the final state. 

3.2.2 Theoretical Operational Semantics uit of CHR in SFC 

The following is the description of the theoretical operational semantics ujt in 
terms of the sorts, relations, functions and axioms of the simple fluent calculus. 

(a) Domain Sorts 

- NATURAL, natural numbers; 

- RU LE, the sort of CHR rules and RU LEJD the sort of the rule identi- 
fiers; 

- CONSTRAINT, the sort of constraints, with the following subsorts: 
BIC (the built-in constraints), with the subsort EQ (constraints in the 
form X = y), and U DC (the user-defined constraints), with the following 
subsort: IDENTIFIED (constraints in the form c#i). In short: 

EQ < BIC < CONSTRAINT and 
IDENTIFIED < UDC < CONSTRAINT; 

- PROPHISTORY = Seq{NATURAL) x RULE, the elements of the 
Propagation History, tuples of a sequence of natural numbers and a rule; 

For each defined sort X, three new sorts: Seq{X), Set{X) and Bag{X) 
containing the sequences, the sets and the bags of elements of X. We use 
[] for the empty sequence and {} for the empty set and the empty bag. 

- CHRACTION < ACTION, the subsort of ACTION containing only 
the actions in the CHR semantics. 

(b) Predicates 

- Query : Bag{CON STRAINT), Query{q) holds iff q is the initial query; 

- Consistent : STATE, holds iff the BICS of the state is consistent (i.e., 
if it does not entail false). 

- Match{hk,hfi,ui,U2,e,z) holds iff (i) ui and U2 are in the UDCS of z 
and (ii) the set of matching equations e is such that chr{ui) — e{hk) and 
chr{u2) = e{hii); 

- Entails : Set{BIC) x Set{EQ) x Bag{BIC), Entail s {b, e, g) holds if 
CT^b^3{eAg). 
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(c) Functions 

- # : UDC X NATURAL ^ IDENTIFIED, defines the syntactic sugar 
for defining identified constraints in the form c^i; 

- makeRule : 

RULEID X Bag{UDC) x Bag{UDC) x Bag{BIC) x Bag{UDC) ^ 
RULE, 

makes a rule from its components. We define the syntactic sugar for rules 
as rid@hk\hii ^ g\b = makeRule{rid, hk, ha, g, b); 

- Bics : STATE i-^ Set{BIC), where Bics{z) {c\Holds{InBics{c), z)}; 

- id : Set{UDC) ^ S et{N ATU RAL) , where id{H) = i\c#i e H 

- The usual set, sequence and bag operations: G for element, U for set 
union, l±) for bag union, H — h for sequence concatenation, | for sequence 
head and tail (Ex: [head\tail]) and \ for set subtraction. 

(d) Fluents 

- Goal : Bag{UDG) FLUENT, Goal{q) holds iff q is the current goal; 

- Udcs : Bag{IDENTIFIED) ^ FLUENT, Udcs{u) holds iff u is the 
current UDCS; 

- InBics : BIG i-^ FLUENT, InBics{c) holds iff c is in the current BICS; 

- InPropHistory : PROPHISTORY FLUENT, InPropHistory{p) 
holds iff p is in the current Propagation History; 

- Nextid : NATURAL ^ FLUENT, Nextld{n) holds iff n is the next 
natural number to be used to identify a identified constraint. 

(e) Actions 

- Solve : BIG H- GHR.AGTION, Do{Solve{c),s) executes the Solve 
transition with the built-in constraint c; 

- Introduce : UDG ^ GHR_AGTION, Do{Introduce{c), s) executes the 
Introduce transition with the user-defined constraint c; 

- Apply : RULE x Bag{UDG) x Bag{UDG) ^ GHR_AGTION, 

D o{ Apply {r, ui, U2), s) executes the Apply transition matching the con- 
straints ui and u2 in the UDGS with the kept and removed heads of 
r. 

(f) Axioms 

- Query{q) State{SO) = Goal{q) o Udcs{{}) o Nextld{l), 

The Initial State Axiom states that in the initial state, the goal contains 
the constraints in the query, the user defined constraint store is empty 
and the next ID for identified constraints is 1; 

Solve 

- Poss{Solve{c),z) = {3q){Holds{Goal{q), z) A c € q) 

The Solve Precondition Axiom states that the only precondition for the 
Solve action on the built-in constraint c is that this constraint should be 
in the goal. 
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- Poss{Solve{c),s) A Holds{Goal{q W {c}), State{s)) D 

State{Do{Solve{c), s)) = State{s) o Goal{q) o InBics(c) — 
Goal{q\±l{c}) 

The Solve State Update Axiom states that the result of the Solve action 
over the constraint c is that this constraint is removed from goal and 
added to InBics list in current state; 

Introduce 

- Poss{Introduce{c), z) = {3q){Holds{Goal{q), z) A c G q) 

- Poss{Introduce(c), s) A Holds{Goal{q W c), State{s))A 

Holds{Udcs{u), State{s)) A Holds{NextId{n), State{s)) D 
State(Do{Introduce{c), s)) ~ State{s) o Goal[q) o Udcs{u W c#7i) o 
Nextld{n + 1)- 

Goal{q l±) {c}) - Udcs{u) - Nextld{n) 

Apply 

- Poss{Apply{r@hk\hR ^ g\d, ui, U2), z) = 

(3e){3b){Match{hk, hn, ui, W2, e, z)A 
-iHolds{InPropHistory{id{ui), id{u2), r), z)f\Bics{b, z)f\Entails{b, e, g)) 

- Poss{Apply{r@hk\hR O g\d, ui, 1*2), State{s))A 

Holds{Udcs{ui 1+1 M2 W u), State{s)) A Holds[Goal{q), State{s))A 
Match{h}:,hft,ui,U2,e, z) D 

State{Do{Apply{r@hk\hR'i^ g\d,ui,U2),s)) = State{s)oGoal{di+lq)o 
Udcs{ul'Su)oInBics{e)oInBics{g)oInInPropHistory{id{ui), id(u2), r) — 
Goal{q) - Udcs{u\ W u2 l±) m) 

3.2.3 Observational Semantics of CHR based on ujt 

The following is the description of the observational semantics of CHR using 
the simple fluent calculus with modified axioms of the Section 2.4.3. Sorts, 
Predicates, Functions and Fluents are the same as in the previous section; there 
is on additional item for the attributes. 

The actions are now constants and we make explicit 4 actions: 
Init, Solve, Introduce, Fail. 

(e) Actions 

- Init :n. CHR_ACTION , Do{Init, [goal{q)\a], s) executes the top-level ini- 
tial transition (starting the resolution) with some query q in the current 
state (a stands for other attributes list in the associated trace event); 

- Solve -.^ CIIR.AGTION, Do{Solve, [bic{c)\a], s) executes the Solve tran- 
sition with the built-in constraint c; 

- Introduce CHR^ACTION, Do{Introduce,[udc(c)\a], s) executes the 
Introduce transition with the user-defined constraint c; 

- Apply :^ CHR.ACTION, 

Do{Apply, [rule{r)\t], s) executes the Apply transition with rule r matching 
the constraints in the U DGS with the kept and removed heads; 
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- Fail -.1-^ CHR_ACTION, Do{Fail, [goal{q)\a], s) if no Apply is possible. 

There are also 5 attributes in the actual trace: goal, udc, bic, hind, rule. 

(f) Attributes 

- goal : CONSTRAINTS ^ ATTRIBUTE, is the set of constraints in the 
current Goal; 

- udc : CONSTRAINTS ATTRIBUTE, is the set of constraints in the 
current User Defined Constraints Store; 

- bic : CONSTRAINTS i-^ ATTRIBUTE, is the set of constraints in the 
current Built-in Constraints Store ; 

- hind :i— >■ INTEGER, is the new propagation history index (incremented by 
Introduce); 

- rule : RULE ^ ATTRIBUTE, is the rule applied to reach this state. 
Apply 

We just comment the adaptation of one rule, the full description is in Ap- 
pendix A. 

(g) Axioms of the Observational Semantics 

- Poss{Apply, [r,hk,hR,g,ui,U2],z) = 

{^e){3b){Match{hk, h^, ui,U2,e, z)A 

—'Holds{InPropIIistory(id{ui), id{u2), r), z) A Bics(b, z)A 
Entailsib, e, g)) 

- Poss{Apply, [r,hk,hR,g,ui,U2],State{s))h 

H olds{U dcs{ui W U2 W u), State{s)) A IIolds{Goal{q), State{s))A 
Match{hk,hf{,ui,U2,e, z) D 
State(Do{Apply , 

[apply, rule{r@hk\hR g\d,ui,U2), goal{d^q), udc{ul^u), bic{g)], s)) = 
State(s) o Goal{d it) q) o Udcs{ul W u) o InBics{e) o InBics{g)o 

InPropHistory(id{ui), id{u2), r) 

-Goal{q) - Udcs{ul l±) u2 l+l u) 

The observational semantics of CHR^ can be formalized similarly with 11 
actions (hence 11 different kinds of trace events), 

initState, solve, activate, reactivate, drop, simplify, propagate, derive, 

clean, split, fail, 
using the refined operational semantics w^, according to [17, 9]. 
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3.3 Towards Full Generic Trace of CHR"^ 

As suggested in the Section 2.3.2, a full trace will be progressively obtained 
by composing several layers of traces and several potential applications in such 
a way that as many as possible of potential uses can be satisfied by such a 
trace. The Figure 5 suggests 4 levels of refinements corresponding to 4 layers 
of implementations, i.e. from bottom to top: environment of execution (Win- 
dows/Linux/Mac...), implementation language (most of CHR are implemented 
in Prolog), CHR, and application written in CHR. There may be other lower 
levels, like WAM abstract machine implemented in Java for the Prolog level, 
etc... Even if each layer has its own level of abstraction and most of the CHR 
users don't care about lower software layers, it may be interesting to keep some 
trace of them in the "full" trace. 

If we consider the point of view of debugging some application written in 
CHR, here are some information which could be usefully found in a trace used 
by a debugging tool. 

• Execution environment: activation of system commands during interac- 
tions 

• Implementation languages (there may be several layers): specific local 
error messages, activated layer, ... 

• CHR: name of used rules 

We mean here that, at some point, it may be useful to find in the trace of 
the application some information regarding different layers of implementation 
in order a debugging tool to be able to "understand" some bugs. 

Let us consider an example of application. In the Annex D we give the 
observational semantics in SFC of a simple application of [53]. This OS specifies 
possible traces of actions performed by robots (here there is only one). We may 
assume that this small world is programmed in CHR and therefore the trace of 
the whole system is a kind of combination of both traces: the one of the robot 
and the trace corresponding to the CHR program execution. The resulting 
full trace corresponds to the trace composition described in the Section 2.3.2 
(comprehensively treated in [15]). 

If one wants just to follow what the robots are doing, then the sub-trace 
consisting of the trace events regarding the robot's actions is sufficiently relevant. 
But, at least at the stage of debugging, some dysfunction observed in the robot's 
trace (for example crossing a closed door) can be understood only by looking at 
a more complete trace which includes events related to the CHR layer behaviour. 

Finally there is one more level, which corresponds to the specificity and 
versatility of CHR: the many extensions and applications which are embedded 
in CHR with CHR as implementation language, quoted as the "CHR world" 
in the introduction. Here are some of them [22]: Boolean algebra for circuit 
analysis, resolution of linear polinomial equations - CLP (7?,)'^- with application 
in finances and non linear equations, finite domain solvers - CLP(FD) - with 
applications in puzzles, scheduling and optimisation, but many others as quoted 
at the beginning of the report. 

*CLP stands for Constraint Logic Programming. 
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A full CHR^ trace should probably include traces related to several exten- 
sions like CLK{X) where X stands for some constraint domain, and CHR^'""-^ 
for example. This is possible, but there is still a need to specify an observational 
semantics for several of these extensions. 
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4 Towards CHROME-REF 

This section details the architecture of CHROME-REF, the extensible imple- 
mentation of a generic tracer for Constraint Solving and Rule-Based Reasoning. 
Each component of the CHROME-REF is described in terms of UML2.1 accord- 
ing the KobrA2 methodology [4, 5]. We first give a brief overview of CHROME. 

4.1 CHROME 

CHROME stands for Constraint Handling Rule Online Model-driven 
Engine, is a model-driven, component-based, scalable, online, Java-hosted CHR' 
engine to lay at the bottom of the framework as the most widely reused auto- 
mated reasoning component. The idea of CHROME is also to demonstrate how 
a standard set of languages and processes prescribed by MDA can be used to 
design concrete artefacts, such as: a versatile inference engine for CHR^ and its 
compiler component that generates from a CHR^ base the source code of Java 
classes. 

4.1.1 Goals and Design Principles 

The main goal of CHROME if to take CHR engines a step beyond, by designing 
a new CHR^ engine and a corresponding compiler using a component-based 
model-driven approach. CHROME is a CHR^ engine with an efficient and 
complete search algorithm (e.g. the conflict-directed backjumping algorithm), 
the first versatile rule-based engine, integrating production rules, rewrite rules, 
its built-in belief revision mechanism (reused for handling disjunctions) and CLP 
rules to run on top of a mainstream Object Oriented (00) platform (Java). 
Because it is a rule-based engine following a component-based model-driven 
approach, it allows easy port to other 00 platforms such as Python, JSP, C++ 
and others. Finally the compiler is the first that uses a model transformation 
pipeline to transform from a source relational-declarative language into a 00 
imperative paradigm language. 

The CHROME architecture is divided into two main sub-components (see 
the Figure 9): 

i) The ATL-pipeline compiler (CHR Compiler component) that takes as input 
a relational declarative CHR^ base and produces an efficient constraint 
handling imperative object-oriented component assembly. 

ii) The CHROME run-time engine (shown in the Figure 9 as the QueryPro- 
cessor component) that provides the services and data structures necessary 
to execute a CHR^ base given a particular query (collection of constraints). 

The Figure 10 shows the complete MOF metamodel of CHR^. At this 
abstract syntax level all CHR^ rules are generalized as simpagation rules. The 
meta-associations keep and del from the CHR^ meta-class to the Constraint 
meta-class respectively represent the propagated and simplified heads of the 
rule. The heads must be instances of RDCs (Rule Defined Constraints). A 
guard of a rule must be a collection of BICs (Builtin Constraints). Both RDCs 
and BICs are specializations of Constraint meta-class. 
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Figure 10: Mcta-modcl of CHR^ and CHR data structures. 
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The body of a CHR^ rule is a collection of alternative conjunctions. Con- 
junctions are composed by both RDC or BIG, e.g. a collection of instances of 
meta-class Constraint. The original CHR^ base has a special RDC (OR) to 
indicate disjunctions in the body. The collection of all rules of a CHR program 
is a CHR Base. 

Each constraint is composed by a constraint symbol and a collection of zero 
or more arguments, e.g. a collection of terms (meta-class Term). A Term 
further specializes into: functional terms, non-functional terms, ground terms 
and non-ground terms. A Constant is both a non-functional term and a ground 
term and a Variable is a non-ground term and a non-functional term. Finally 
a functional term is further composed by a Function Symbol and a collection 
of zero or more arguments, which are in turn recursively defined as instances of 
meta-class Term. The constraint domain meta-class aggregates all term symbols 
allowed. 

The metamodel displays also the internal structures of the engine, namely: 
the constraint store and the constraint queue. The first stores the constraints 
added by firing rules, the second is a processing queue that tracks which is the 
next constraint to be processed. 

4.1.2 Strengths and Limitations 

CHROME is the first Java CHR^ engine: none of the related CHR Java engines 
allow disjunctive rules. Compilation in Java makes it easier to reuse and de- 
ploy full CHR^ bases in applications in need of automated reasoning services. 
It is one of the largest case study to date to integrate MDE technology with 
model transformations (4358 ATL lines) and components. It however suffers 
some limitations, as it provides only three built-in constraints: the syntactical 
equality, true and false, and it has no visual tracing IDE. This makes practical 
applications still too cumbersome to implement, being tracing a fundamental 
part of large automated reasoning development. 

4.2 CHROME-REF Components 

The Figure 11 shows a object-oriented representation of the observational se- 
mantics of CHR^ as described in the Section 3.2.1. It contains five sort of 
extracted trace events (ETrace): an initial state {E Initial State), user-defined 
contraint store introduced (E Introduce), built-in introduced (E Solve), rule ap- 
plied (E Apply) and rule failed {EE ail). 

The top-level CHROME-REF component encapsulates all sub-components 
that compose the CHROME environment. The Figure 12 shows the main com- 
ponent and its three sub-components as defined in what follows. They provide 
methods to compile a rule base, to solve a query (displaying one or more solu- 
tions for such query) , to adapt a solution when a given set of justified constraints 
is deleted and to clear the constraint store for processing a new query. 

The Driver component is a intermediator between CHROME and Analyzer, 
its function is to manager the communication of trace event sent by the engine 
and filter the requested information to the analyzer. Finally, the Analyzer 
component, in our case, is a debugging tool for CHR. 

The next sub-sections describe each component. 
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Figure 11: 00 Representation of the OS of the CHR"^ Tracer 
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Figure 13: Insertion of the Trace Extraction Component into CHROME 



4.2.1 Extraction 

The Figure 13 shows the CHROME component with a new component called 
TraceExtraction, which implements the generic CHR trace as described in the 
Section 3.2.3. 

We have added two improvements to the CHROME to integrate with our 
proposal: a new componente called Trace Extraction that receives as input some 
parameters {Constraint^ QueryProcessorandRDC) and produces the trace events 
(ETrace); and, we included new rules into the CHROME compiler to send the 
previous parameters to the Trace Extraction during the execution of a CHR 
program. 

The following OCL rules explain how a trace event will be produced from 
received parameters: 

context TraceExtraction: :genEIiiitialState{qp:QueryProcessor) :-<-^ 

Etrace 
post: 

let e Ini t i al St at e : EIni t i al St at e = oclIsNew() 
in 

eInitialState . query = qp . goal and 
result = eInitialState 

context Tr ac eExtr act i on :: genEInt reduce ( c : Constraint , qp : -f^ 

QueryProcessor ) : Etrace 
post: 

let eintroduce : EIntroduce = oclIsNew() 
in 

eintroduce.c = c and 

eintroduce . udcs = qp . cs . getStore ( ) and 
result = eintroduce 

context TraceExtraction : : genESolve (bic : Constraint , qp : •<-^ 

QueryProcessor) : Etrace 
post: 

let eSolve : ESolve = oclIsNew() 
in 

eSolve . bic = bic and 

eSolve . builtlns = qp.allVars and 
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Figure 14: Trace Driver Meta-model 



result = eSolve 

context TraceExtraction:: genE Apply (rule:RDC) lEtrace 
post: 

let eApply : EApply = ocllsNew() 
in 

eApply . rule = rule and 
result = eApply 

context TraceExtraction : : genEFail (rule :RDC) :Etrace 
post: 

let eFail:EFail = oclIsNew() 
in 

eFail . rule = rule and 
result = eFatil 



4.2.2 Driver 

The Trace Driver component is an intermediator between a process and an 
analyzer. It component has the foUowing functions (Figure 14): 

• to decide whether the underlying process (in our case CHROME) wiU send 
trace events step by step or aU at once. This information is represented 
by means of the flag stepByStep; 

• to register an analyzer that will watch the trace events from the underlying 
process; 

• to notify all connected analyzers soon after a trace event to be produced; 

• to ask for a new trace event (only if the flag stepByStep is true); and, 

• to fllter a trace event by means of a trace query sent from a analyzer. 
The following OCL rules describe the post-condition of each method: 



context TraceDriver ::registerAnalyzer (a: Analyzer) 
post: analy zer — >include s ( d ) 



context TraceDriver ;: notifyDriver ( eTrace : ETrace ) 
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Figure 15: Mcta-model of the Analyzer and Communication with the Driver 



post: analyzers— >forAll ( a | a ' not i f i cat i on ( f i It erTr ace ( a . r equest 
eTrace ) ) ) 

context TraceDriver ::n6wStep() 
post: observed . newStep { ) 

context TraceDriver:: up dateFilter(a: Analyzer, request: Request) 
post: a. request = request 

As said before, the Trace Driver component is a intermediator that receives 
trace events from a process and sends it to the analyzer. The Figure 15 shows 
the relationships between these components. 

A trace driver is connected to an observed process which sends the trace 
events, and it has a list of analyzers to which to the trace events. Each analyzer 
is associated to a query, which says which information the driver will send to 
the analyzer. 

4.2.3 Analyzer 

The trace analyzer specifies to the driver which events are needed by means 
of queries. The requests that an analyzer can send to the tracer driver are of 
three kind. Firstly, the analyzer can ask for additional data about the current 
event. Secondly, the analyzer can modify the query to be checked by the driver. 
Thirdly, the analyzer can notify the driver to pause, continue or end the process 
execution. 

In this project, in order to exemplify the whole proposed framework, we 
have created two simple views to show a pretty-printing of a CHR execution. 
The Figure 16 presents these two kind of analyzers: the Trace View shows 
the evolution of the CHR parameters (Goal, Constraint Store, Built-ins, etc), 
defined in the generic trace; and the Program View is just to focus in a specific 
rule when this rule is triggered. 

We illustrate these views with an execution of the LEQ example. 

reflexivity (8 leq(X,Y) <=> X=Y | true. 

antisymetry leq(X,Y) , leq{Y,X) <=> X=Y . 

idempotence l6q(X,Y) \ leq(X,Y) <=> true. 

transitivity leq{X,Y) , leq(Y,Z) <=> leq(X,Z). 

with the query: 
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Figure 16: A Simple GUI to Analyze a Program Execution Looking at its Trace 



leq(A,B), leq(B,C), leq(C,A). 

Finally, we get the XML instance produced by CHROME for this example 
(see complete trace with all attributes in the Appendix C). 



<?xnil ver sion=" 1.0" encoding— 'UTF— 8" ?> 
<chrv 

xinlns=" http : / / orcas . org . br / chrv" 

xmlns : xsi=" http : / /www. w3 . org /2001 /XMLSchema-ins t ance " 
xsi : schemaLocation= 

"'http : / / orcas . org . br/chrv chrv.xsd"> 
<event chrono— ' 1"> 

<initialState> 

<goal>leq (A , B) , leq(B,C) , leq ( C , A ) </goal> 

</initialState> 
</event > 

<event chrono=" 2' > 
<introduce> 

<udc>leq(A ,B)</udc> 
<goal>leq(B ,0) , leq ( C , A ) </goal> 
</introduce> 
</event > 

<event chrono=" 3''> 
<introduce> 

<udc>leq(A ,B) , leq (B , C ) </udc> 
<goal>leq(C , A)</goal> 

</chrv> 

At this stage of the implementation, such views are principally helpful to 
help to develop the generic trace. 
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5 Conclusion 

In this report we have presented an ongoing work as a roadniap towards CHROME- 
REF, and we have defined the methods and tools to reach this goal They con- 
sists of a formal specification (called observational semantics - OS) of a generic 
tracer for CHR^ using an adaptation of the simple fluent calculus (SEC) which 
we have presented, and its implementation, over and inside CHROME, using 
the KobrA2 method, and rcsuhing in a PIM of CHROME-REE. 

We have tested the approach with a small trace pretty printing GUI. We 
also indicated how to work on extensions of the very first trace we presented 
(using the simple w* semantics of CHR), before including other actions and at- 
tributes inspired by more refined semantics of CHR^ and various CHR domains 
extensions. 

Several other issues however remain to be explored. 

Eirst the use of the SEC to describe the observational semantics of tracers. 
As quoted in the report, we may expect several advantages of its use: facili- 
tation of trace extension specification, or refinement, by merging observational 
semantics of several CHR extensions or sublayers, and facilitation of verification 
of formal properties of the trace. We did not reach the point to be in condition 
to simulate production of traces trying to execute this OS using Elux. Such 
execution would require some implementation of complex functions or predi- 
cates. Since the OS may be a smooth abstraction of a family of solvers, it is 
in principle possible to develop some simulation producing supersets of possible 
traces. This can be useful to analyse some properties of the traces to improve 
their design. However it will become worth and more interesting when a more 
refined full trace will be ready. 

Another point which remains unsolved is the way to relate the observational 
semantics of the tracer and the design of the CHROME-REE PIM. Both are 
forms of partial formal specification. The OS because it is an abstraction of the 
semantics of the observed process - hence a partial specification-, the later be- 
cause it is a partially formal specification. Even if it is clear that the description 
of the tracer in SEC is a clear requirement which serves as guideline to design 
this PIM, there is no way to guarantee a formal correspondence. 

One proposed approach is to map the logical model of SEC used here into an 
Object-Oriented (00) model (OOSEC), and to limit the "implementation step" 
to a merging of PIMs. This way to proceed is illustrated on the Eigurc 17. This 
approach aims at reducing the complexity of mapping between the two different 
descriptions, by introducing a intermediary step denoted CHR-OSoosi^c- 

We have started to specify the OS in OOSEC [39], but this question is still 
open whether this step is really helping, or whether the construction of the 
tracer part of the CHROME-REE PIM in UML is better achieved just using 
the SEC specification of the OS. It could be also interesting to compare several 
approaches of extending existing codes, like pluging aspects in the CHROME 
java code. In any cases the question of the relationships with the specification 
is still worth posing. 

Einally a third unsolved point concerns the validation of the implementa- 
tion. Considering the design and implementation used method, there is no way 
to make formal proof of adequation between the specification and the imple- 
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Figure 17: An Intermediate Step towards CHROME-REF 
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Figure 18: Validating dilFcrent operational semantics 



mentation, but this point need more study. At this stage, we are limited to 
perform tests. The Figure 18 illustrates this point. 

• Semi- formal proof: It is to show that CHR-OSfc is equivalent to the 
CHROME-REF^/A/i. But, as UML is a semi-formal language [33], so that, 
UML is not stricly formal in sense of a purely syntactic derivation using a 
very precise and circumscribed formal set of rules of inference, no formal 
proof can be performed. 

• Test-based validation: Let CHR-OSi^c with its equivalent implemen- 
tation CHR-OSFiiiK in Flux, and CHROME- REF[/ml with its equivalent 
implementation in Java CHROME- REFja^ja, the method consists of com- 
paring the produced traces to check whether they are equivalent. 

There is still a long way to get a full generic trace for CHR. Indeed, as quoted 
in the Section 3.3, such goal implies the existence of generic traces for several 
CHR extensions. Since we already have some (for finite domain solvers, or for 
Prolog under-layer for example), we are far to cover all existing extensions of 
CHR quoted at the beginning of this paper. But the composition of traces and 
the method of implementing tracer presented here give a possible road towards 
a full generic trace for CHR^ and many of its extensions. 
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A Appendix - Observational Semantics of CHR 

The following is the description of the observational semantics of CHR based 
on its theoretical operational semantics Wt and the simple fluent calculus with 
modified axioms of the Section 2.4.3. 

(a) Domain Sorts 

- NATURAL, natural numbers; 

- RULE, the sort of CHR rules and RULEJD the sort of the rule identi- 
fiers; 

- CONSTRALNT, the sort of constraints, with the following subsorts: 
BIC (the built-in constraints), with the subsort EQ (constraints in the 
form X = y), and UDC (the user-defined constraints), with the following 
subsort: IDENTLFLED (constraints in the form c^i). In short: 

EQ < BLC < CONSTRAINT and 
IDENTIFIED < UDC < CONSTRAINT; 

- PROPHISTORY = Seq{NATURAL) x RULE, the elements of the 
Propagation History, tuples of a sequence of natural numbers and a rule. 
For each defined sort X, three new sorts: Seq{X), Set{X) and Bag{X) 
containing the sequences, the sets and the bags of elements of X. We use 
[] for the empty sequence and {} for the empty set and the empty bag. 

- CHRACTION < ACTION, the subsort of ACTION containing only 
the actions in the CHR semantics. 

(b) Predicates 

- Query : Bag{CON STRAINT), Query {q) holds iff q is the initial query; 

- Consistent : STATE, holds iff the BICS of the state is consistent (i.e., 
if it does not entail false) ; 

- AIatch{hk,hfi,ui,U2,e,z) holds iff (i) ui and U2 are in the UDCS of z 
and (ii) the set of matching equations e is such that chr(ui) = e{hk) and 
chr{u2) = e(/ifl); 

- Entails : Set{BIC) x Set{EQ) x Bag{BIC), Entailslb,e,g) holds if 
CT^b^3{eAg). 

(c) Functions 

- # : UDC X NATURAL ^ IDENTIFIED, defines the syntactic sugar 
for defining identified constraints in the form c^i; 

- makeRule : 

RULEID X Bag{UDC) x Bag{UDC) x Bag{BIC) x Bag{UDC) ^ 
RULE, makes a rule from its components. We define the syntactic sugar 
for rules as rid@hk\hfi o g\b ~ makeRule{rid, hk, hn, g, b); 

- Bics : STATE Set{BIC), where Bics{z) = {c\Holds{InBics{c), z)}; 

- id : Set{UDC) ^ S et{N ATU RAL) , where id{H) = i\c#i e H 
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- The usual set, sequence and bag operations: G for pertinence, U for set 
union, tiJ for bag union, H — h for sequence concatenation, | for sequence 
head and tail (Ex: [head\tail]) and \ for set subtraction. 

(d) Fluents 

- Query : Bag{UDC) ^ FLUENT, Query{q) holds iff q is the initial 
toplevel goal; 

- Goal : Bag{UDG) ^ FLUENT, Goal{q) holds iff q is the current goal; 

- Udcs : Bag{IDENTIFIED) ^ FLUENT, Udcs{u) holds iff u is the 
current UDCS; 

- InBics : BLG i-^ FLUENT, InBics{c) holds iff c is in the current BICS; 

- InPropHistory : PROPHISTORY ^ FLUENT, InPropHistory{p) 
holds iff p is in the current Propagation History; 

- Nextid : NATURAL ^ FLUENT, Nextld{n) holds iff n is the next 
natural number to be used to identify a identified constraint. 

(e) Actions 

- Init :M' CHR_ACTI0N , Do{Init,\goal{q)\a],s) executes the toplevel 
initial transition (starting the resolution) with some query q in the current 
state (a stands for other attributes list in the associated trace event); 

- Solve :k> GHR.AGTION, Do{Solve,[bic{c)\a], s) executes the Solve 
transition with the built-in constraint c; 

- Introduce -.^ GH REACTION, Do{Introduce, [udc{c)\a], s) executes the 
Introduce transition with the user-defined constraint c; 

- Apply -.^ GHR.AGTION, 

Do{Apply, [rule(r)\t\, s) executes the Apply transition with rule r match- 
ing the constraints in the UDGS with the kept and removed heads; 

- Fail :i-> CHR_AGTION, Do{Init,[goal{q)\a], s) executes the toplevel 
initial transition (starting the resolution) with some query q in the current 
state (a stands for other attributes list in the associated trace event); 

(f) Attributes 

- goal : CONSTRAINTS ^ ATTRIBUTE, is the set of constraints in 
the current Goal; 

- udc : CONSTRAINTS i-^ ATTRIBUTE, is the set of constraints in 
the current User Defined Constraints Store; 

- bic : CONSTRAINTS ATTRIBUTE, is the set of constraints in the 
current Built-in Constraints Store ; 

- hind :i~> INTEGER, is the new propagation history index (incremented 
by Introduce); 

- rule : RULE ATTRIBUTE, is the rule applied to reach this state. 
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(g) Axioms of the Observational Semantics 
Init 

- Poss{Init, [q\, z) = H olds (Query (q), z) 

- Poss{Init,[q\, State{s)) D State{Do{Init,[mitState, goal{q), hind{l)], s)) = 

State{s) o Udcs{{}) o Goal{q) o Nextld{l)- 
Query{q) 

The Initial State Axiom states that in the initial state, the goal contains 
the constraints in the query, the user defined constraint store is empty 
and the next ID for identified constraints is 1; 

Solve 

- Poss{Solve,[c],z) = {3q){Holds{Goal{q\i^{c}),z) 

The Solve Precondition Axiom states that the only precondition for the 
Solve action on the built-in constraint c is that this constraint should be 
in the goal. 

- Poss{Solve, [c], s) D 

State{Do{Solve, [so\ve,hic{c),goal(q)\^s)) = 
State(s) o Goal{q) o InBics{c) — Goal{q W {c}) 
The Solve State Update Axiom states that the result of the Solve action 
over the constraint c is that this constraint is removed from goal and 
added to InBics list in current state; 

Introduce 

- Poss{Introduce, [c], z) = {3q){H olds{Goal{q) , z) Ac £ q) 

- Poss{Introduce, [c], State{s)) A Holds{Udcs{u), State{s))A 

Holds{NextId{n),State{s)) D 
State{Do{Intr educe, [introduce, udcic), goal{q), hindin + 1)], s)) = 
State{s) o Goal{q) o Udcs{u tt) c#n) o Nextld{n + 1)- 
Goal{q 1+1 {c}) - Udcs{u) - Nextld{n) 

Apply 

- Poss{Apply, [r,hk,hR,g,ui,U2],z) = 

{3e){3b){Match{hk, hfj, ui,U2, e, z)A 

-^Holds{InPropHistory{id(ui),id{u2),r), z) A Bics{b, z)A 
Entails{b, e, g)) 

- Poss{Apply, [r, hk, hn, g,ui,U2], State{s))A 

Holds{Udcs{ui 1+) M2 W u), State{s)) A Holds{Goal{q), State{s))A 
Match{hk, hfi, ui, M2, e, z) D 
State[Do{Apply , 

[apply, rule{r@hk\hii -s-> g\d, ui, U2), goal{d^q), udc(ull±lu), bic{g)], s)) = 
State{s) o Goal{d kil q) o U dcs{ul l±) u) o InBics{e) o InBics{g)o 
InPropHistory{id{ui), id(u2), r) 
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-Goal{q) - Udcs{ul y u2 l±) u) 

Fail 

- Poss{Fail, [q],z) = Holds{goal{q), z)/\ flPoss{Apply, [r, hk, h]i,g, ui, U2], z) 

- Poss(Fail, [q], s) D 

State(Do{Fail, [iail, goal{q)], s)) — State{s) 
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B Appendix - XML schema for Generic CHR 
Trace 

<? xml version=' 1 .0" encoding—'UTF— 8" ?> 
<xs:schema xmlns: xs=" ht t p : / /www. w3 . org/2001 /XMLSchema" 

t ar get Names pace=" http: / /orcas .org.br/chrv" xmlns=" http; / / orcas-(-^ 

. org . br/ chrv" 
element For mDefault—' qualified "> 
<xs:element name="chrv"> 
<xs:complexType> 
<xs;sequence> 

<xs:element name=" event" minOccurs—' 0" maxOccurs—' unbounded" -(-^ 
> 

<xs:complexTypc> 
<xs : choice> 

<xs:element namc=" i n i t i a 1 S t a t e " minOccurs=" 1" maxOccurs—' -(-^ 
1"> 

<xs: complexTypc> 
<xs:sequence> 
<xs:element name="goal" type—' x s : s t r i n g " /> 
<xs:element name="hind" type—' x s : i n t c ge r " /> 
</xs:sequence> 
</xs : complexType> 
</xs:element> 

<xs:element name=" i nt r oduce " minOccurs—' 1 " maxOccurs—' 1"> 
<xs :complexType> 
<xs:sequence> 
<xs; element name="udc" type=" x s : s t r i n g " /> 
<xs;element name="goal" ty pe=" x s : s t r i n g " /> 
<xs:element name="hind" type—' x s ; i n t c g c r " /> 
</xs:sequence> 
</ xs:complexType> 
</xs:element> 

<xs:element name=" solve" minOccurs='' 1 " maxOccurs=" 1 "> 
<xs:complexType> 
<xs:sequence> 
<xs;element name="bic" type—' x s : s t r i n g " /> 
<xs:element name="goal" type—' x s : s t r i n g " /> 
</xs:sequence> 
</xs : complexType> 
</xs:element> 

<xs:elcmcnt name=" apply" minOccurs=" 1 " maxOccurs=" 1 "> 
<xs :complexType> 
<xs : sequence> 
<xs;element name—' rule" type—' x s : s t r i n g " /> 
<xs;element namc="goal" type—' x s : s t r i n g " /> 
<xs; element namc="udc" ty pe=" x s : s t r i n g " /> 
<xs;element name="bic" type—' xs : s t r i n g " /> 
</xs:sequence> 
</ xs : complexType> 
</ xs:element> 
<xs:element name—' fail" minOccurs='' 1 " maxOccurs—' 1 "> 
<xs:complexType> 
<xs:sequence> 

<xs:element name—' rule" type—' x s ; s t r i n g " /> 
</ xs:sequence> 
</ xs:complexType> 
</xs:element> 
</ xs : choicc> 
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<xs : a 1 1 r i b u t c name=" chrono" ty pe=" x s : s t r i n g " use—'-^^ 
required" /> 
</ xs:complexType> 
</xs:element> 
</xs:sequence> 
</xs : complcxTypc> 
<xs: unique name—' chronoKey " /> 
<xs;sclcctor xpath—' event " /> 
<xs:field xpath—' ©chrono" /> 
</ xs ; unique> 
</xs:element> 
</ xs:schema> 
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C Appendix - LEQ Example Execution Trace 

Here is the trace of execution of the LEQ the Example 3.1 executed in CHROME- 
REF. 



<? xml version— ' I .0" encoding—'UTF— 8" ?> 
<chrv 

xmlns—' http: // orcas . org . br/chrv" 

xmlns:xsi="http: / /www. w3 . org/2001/ XMLSchema^ i n s t a n c e " 
xsi : schemaLocat ion= 

" http: / / orcas . org . br/ chrv chrv2 . xsd"> 
<event chrono="l"> 
<initialState> 

<goal> leq(A,B), leq(B,C), leq(C,A) </goal> 
<hind> 1 </hind> 
</ initialState> 
</ event> 

<event chrono="2"> 
<introduce> 

<udc> leq(A,B) </udc> 
<goal> leq(B,C), leq(C,A) </goal> 
<hind> 2 </hind> 
</ introducc> 
</ event> 

<event chrono— '■3"> 
<introduce> 

<udc> leq(A,B), leq(B,C) </udc> 
<goal> leq(C,A)) </goal> 
<hind> 3 </hind> 
</ introduce> 
</ event> 

<event chrono='' 1"> 
<apply> 

<rulc> r4a leq(A,B), leq(B,C) => leq(A,C) </rulc> 
<goal> leq(C,A), leq(A,C) </goal> 
</ apply> 
</ event> 

<event chrono="5"> 
<introducc> 

<udc> leq(A,B), leq(B,C), leq(A,C) </udc> 
<goal>leq(C , A)</goal> 
<hind> 4 </hind> 
</ introducO 
</ event> 

<event chrono="6"> 
<introduce> 

<udc> leq(A,B), leq(B,C), leq(A,C), leq(C,A) </udc> 
<goal> </goal> 
<hind> 5 </hind> 
</ introducO 
</ cvcnt> 

<event chrono="7"> 
<apply> 

<rule> r2@ leq(A,C), leq(C,A) => A=C </rule> 
<goal> </goal> 

<udc> leq(C,B), leq(B,C) </udc> 
<bic> A=C </bic> 
</apply> 
</ evcnt> 

<event chrono="8"> 
<apply> 
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<rulc> r2a leq(C,B), leq(B,C) => C=B </rulc> 
<goal> </goal> 
<udc> </udc> 
<bic> A=C , C=B </bic> 
</ apply> 
</ evont> 
</ chrv> 

No more LEQ program rule may apply. 



Using a representation where attributes have the functional form used in 
the Observational Semantics, it corresponds to the trace (attributes with empty 
argument are omitted): 

See Appendix A for the meaning of the attributes. 

1 initialState goal((leq(A,B) , leq(B,C), leq(C,A)))) 

hind(l) 

2 introduce udc ( (leq(A,B) ) ) 

goal((leq(B,C) , leq(C,A))) 
hind (2) 

3 introduce udc((leq(A,B) , leq(B,C))) 

goal((leq(C,A))) 
hind (3) 

4 apply rule((r4@ leq(A,B), leq(B,C) ==> leq(A,C))) 

goal((leq(C,A) , leq(A,C))) 

5 introduce udc((leq(A,B) , leq(B,C), leq(A,C))) 

goal((leq(C,B))) 
hind (4) 

6 introduce udc((leq(A,B) , leq(B,C), leq(A,C), leq(C,A))) 

hind (5) 

7 apply rule((r2@ leq(A,C), leq(C,A) ==> A=C)), 

udc(leq(C,B) , leq(B,C)) 
bic((A=C)) 



apply rule((r2@ leq(C,B), leq(B,C) ==> C=B)), 

bic((A=C, C=B )) 
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D Appendix - OS of a Robots Application in 
SFC 

This world consists of agents (the robots) moving in a space structured by rooms 
connected by doors, able to carry objects they find in the rooms. A requisition 
is an order to seek for objects and carry them from some place to an other one. 
The scene description at some moment is the current state and consists of a set 
of facts. A "situation" corresponds to a succession of trace events. The current 
state corresponding to a given situation is obtained here by the reconstruction 
function (interpretation semantics). 

In fluent calculus, facts are named "fluents" and requisitions (or requests) are 
similar to Prolog goals. The way the requisitions are computed is not described 
by the observational semantics. The requests are thus treated as influence fac- 
tors. 

We describe a simplified version of the example of [53] with 3 rooms. 
The simplified robot's world is depicted on Figure 19. 
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Figure 19: A simple robot world 

Initially there is one object and one robot both located in the same room, 
and the door dl2 is locked. The robot has its key. 

We present an implementation of the OS in Flux. A current state is described 
by a set of atoms. 

ACTIONS TYPES 

pickup pick an object (if any) 

drop drop the carried object (if any) 

gotodoor go to the quoted door (if any) 

enteroom enter the quoted room (if the door is open) 

open open the door (if it is closed) 

TRACE EVENTS [attributes] 

Attribute a stands for "agent" 
Attribute o stands for "object" 
Attribute r stands for "room" 
Attribute d stands for "door" 

pickup a o r 
drop a o r 
walk a d 
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walk a r 
open a d 

• Domains 



Domain Sorts 


AGENT 


Al 


ROOM 


i?l, i?2, i?3 


DOOR 


D12,D13 


OBJECT 


01,02,03 



• Parameters 



Parameters versus Fluents 


parameter 


type 


meaning 


AgentlnRoom 


AGENT X ROOM FLUENT 


the agent is in room r 


AtDoor 


AGENT X DOOR i-^ FLUENT 


the agent is at door d 


Closed 


DOOR FLUENT 


door d is closed 


Carries 


AGENT X OBJECT FLUENT 


agent carries object o 


HasKeyCode 


AGENT X DOOR i-^ FLUENT 


agent has the key code for door d 


ObjectlnRoom 


OBJECT X ROOM FLUENT 


the object is in room r 


Request 


ROOM X OBJECT X ROOM h+ FLUENT 


there is a request to deliver 






object o from room rj to room r2 



Each parameter may be represented by several fluents. (Request is treated 
as external) 

The initial state is formalized by this term below. 

Holds{AgentInRoom{Al, R2), So)AHolds{ObjectInRoom{01, i?3), S'o)A 
Holds{ObjectInRoom{02, Rl), So)AHolds{ObjectInRoom{03, i?2), So)A 

Holds{Closed{D12), Sq) A Holds{HasKeyCode{Al, D13), So) A 
Holds{Request{R3, 01, R2), So) A Holds{Request{Rl, 02, R3),So) A 
Holds{Request\R2, 03, i?l), So) A {'ix)^Holds{Carries{Al, x),So) 



• Auxiliary Predicates 



Auxiliary Predicates 


predicate 


type 


meaning 


Connects 


ROOM X DOOR X ROOM 


door d connects rooms ri and r2 



• Actions and Actual state Attributes 



Actions 


action 


attributes 


action meaning 


Pickup 
Drop 

GoToDoor 

EnterRoom 

Open 


pickup X AGENT x OBJECT x ROOM 
drop X AGENT x DOOR x ROOM 
walk X AGENT x DOOR 
walk X AGENT x ROOM 
open X DOOR 


pick up object o 
drop object o 
go to door d 
enter room r 
open door d 
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The parameters of the actions in a condition are just used for communica- 
tion of particular values and thus avoid rewriting of "Holds" conditions in the 
following axiom. 

Observational Semantics 

Pickup 

Poss{Pickup, [a, o, r], s) = 

Holds{AgentInRoom{a, r), s) A H olds{Obj ectInRoom{o, r), s)A 
-'Holds{Carries{a, o))) 

Poss(Pickup, [a, o, r], s) D 

State{Do{Pickup, [pickup, a, o, r], s)) = State{s) o Carries{a, o) 

Drop 

Poss{Drop, [a, o, r] , s) = 

H olds{C arries{a, o)) A Holds{AgentInRoom{a, r), s) 

Poss{Drop, [a, o, r\,s) D 

State{Do{Drop, [drop,a,o,r\, s)) — State{s) — Carries[a,o) 

GoToDoor 

PossiGoToDoor, [a, d, r], s) = Holds{AgentInRoom(a, r), s)A 
{3r')Connects{r, d, r') A ^{3d')Holds{AtDoor{a, d'), s) 

Po3s{GoToDoor, [a, d, r], s) D 

State{Do{GoToDoor, [walk, a, d], s)) = State{s) o AtDoor{a, d) 

EnterRoom 

Poss{EnterRoom, [a, r, d, r'], s) = Holds(AgentInRoom(a, r))A 

Holds{AtDoor{a, d),s) A Connects{r, d, r') A ^Holds{Closed{d), s j) 

Poss{EnterRoom, [a, r, d, r'] , s) Z) 

State{Do{EnterRoom, [walk,a,r'], s)) = State{s)oAgentInRoom{a,r') — 
AgentInRoom{a, r) 

Open 

PossiOpen, [a, d], s) = 

Holds {At Door (a, d), s) A Holds{HasKeyCode{a, d), s)A 
H olds{Closed{d) , s) 

Poss{Open, [a, d], s) D 

State(Do{Open, [open, a, d], s)) ~ State{s) — Closed{d) 
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Example of trace: 



1 


pickup 


al 


ol 


rl 


2 


walk 


al 


dl2 




3 


open 


al 


dl2 




4 


walk 


al 


r2 




5 


walk 


al 


dl2 




6 


walk 


al 


rl 




7 


drop 


al 


ol 


rl 


8 


pickup 


al 


ol 


rl 


9 


drop 


al 


ol 


rl 


10 


walk 


al 


dl3 
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